EXCEPTION_ACCESS_VIOLATION error reloaded

llandale - Wed May 11 14:53:38 EDT 2011
Don't know. I get these exception violations a lot and I can say that the dump below has NEVER been useful to me.
There is almost always also displayed a DXL window showing the line number that generated the error,
and that's a lot more useful.

• Louie

vasgyuszi - Wed May 11 15:48:20 EDT 2011
Yes, I was looking on it: it points always to a line, where I open a module for reading without displaing it.
But the my problem is, that newly scripts crashes which run without any failure in the past.
My current script construct contains three scripts, with alot of module operations:

1a - open source modules in a particular baseline version and view
1b - copy all its displayed objects with the displayed attributes/columns
1c - create the new module and place into this objects, rebuild the view and save it

2a - links all this new modules together (test case, low level, high level, system level modules)

3a - crosscheck of system level requirement modules for various points

1d - create baseline set definition, add all the modules to the definition
1e - create baseline set and baseline all the modules

That's it.

1,2,3 are the script files
They are separate existing and until yesterday run very well if I operate by hand each after each.
Sometimes crashed the first script during copiing the objects, in other times the link script and at least newly the cross check script. Very suspicious that in every case stops at line where I try to open a module like m=read(mdlFullname, false). Very curious...

Thanks in advance,
vasgyuszi

Mathias Mamsch - Wed May 11 17:29:38 EDT 2011
Chances are, that you made DOORS unstable through some buggy code. I cannot really remember any code, that would make opening a module crash. Louie? And idea?

Can you give some information, if you do pass any variables to or from the eval_ statements? A lot of times those crashes will occur because some variable became invalid, but in your case this would have to be the string, to make sense of the crash. Otherwise if you post the scripts, somebody might take a look, but like this it is very hard to tell.

Regards, Mathias

Mathias Mamsch - Wed May 11 17:29:38 EDT 2011
Chances are, that you made DOORS unstable through some buggy code. I cannot really remember any code, that would make opening a module crash. Louie? And idea?

Can you give some information, if you do pass any variables to or from the eval_ statements? A lot of times those crashes will occur because some variable became invalid, but in your case this would have to be the string, to make sense of the crash. Otherwise if you post the scripts, somebody might take a look, but like this it is very hard to tell.

Regards, Mathias

vasgyuszi - Thu May 12 15:40:52 EDT 2011

Now, I've identified the critical zone:

The scripts crash alwas at a special module with newly created views. There are three formal modules to be handled as exceptional. For this modules I wrote an additional function to ste some special filters and save this filtered status as additional view.
For every newly created module I make one view called "Export view". That means every module has the system owned "standard view" and my creation. The former mentioned three formal modules get two additional views by calling this function:

void prepareView (string mNam, string vNam)
{
 
    Module m
 
    m = read(mNam, true)
    if (null m) {errorBox "Module couldn't open: " mNam; return}
 
    string nam
    for nam in views m do if (nam == vNam) delete view vNam
 
    View v = view(vNam) // create the view newly
 
    Filter f
  
    Filter f_reqid
    
    Buffer vNamBuf = create
    vNamBuf = vNam
    if(-1!=contains(vNamBuf,"CPLD",0)) f_reqid = contains (attribute "Req.ID", "PLD_", true)
    else f_reqid = !contains (attribute "Req.ID", "PLD_", true)
 
    Filter f_objhead   = notNull attribute "Object Heading"
    Filter f_reqtype   = attribute "Req.-Type" == "SW"
    Filter f_alloc     = attribute "Allocation" == "SW"
    Filter f_radiotype = contains(attribute "RadioType", "M3AR Family", true) ||
                         contains(attribute "RadioType", "MR6000A",     true) ||
                         contains(attribute "RadioType", "MR6000Aenh",  true)
    
    Buffer mNamBuf = create
    mNamBuf = fullName m
    
    if     (-1!=contains(mNamBuf,"TC_", 0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "TC_", true)  && f_alloc     && f_radiotype )
    else if(-1!=contains(mNamBuf,"LLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "LLR_", true) && f_radiotype                )
    else if(-1!=contains(mNamBuf,"HLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "HLR_", true) && f_reqtype   && f_radiotype )
    else if(-1!=contains(mNamBuf,"SLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "SLR_", true) && f_radiotype )
    else errorBox "There is no appropriate DOORS module to filter." // no appropriate DOORS module
 
    set(m,f)
    filtering on
    showDeletedObjects(false)
 
    setempty(mNamBuf)
    delete(mNamBuf)
 
    setempty(vNamBuf)
    delete(vNamBuf)
      
    ViewDef vDef = createPublic(m, true)
    useCurrent(vDef,true)
    useWindows(vDef,true)
    save (v, vDef)
 
    close m
 
}//void prepareView (string mNam, string vNam)

I call it as follows:

prepareView(trgPrj fldModules "/HRCX/TC_HRCX"    , "CRCx DO-Release view")
        prepareView(trgPrj fldModules "/HRCX/LLR_SW_HRCX", "CRCx DO-Release view")
        prepareView(trgPrj fldModules "/HRCX/HLR_HRCX"   , "CRCx DO-Release view")
 
        prepareView(trgPrj fldModules "/HRCX/TC_HRCX"    , "CPLD DO-Release view")
        prepareView(trgPrj fldModules "/HRCX/LLR_SW_HRCX", "CPLD DO-Release view")
        prepareView(trgPrj fldModules "/HRCX/HLR_HRCX"   , "CPLD DO-Release view")

After successful creation have TC, LLR and HLR modules the two additional filtered views.
For couple of days started my canossa with this call, it crashed always by calling the function at second time for the same module. I don't know why, currently seems to be running. But the remaining part of the script and the other two scripts crashing during processing this prepared modules. Interesting that always at the LLR module crashes which is the second in the line. I do processing on TC first, than LLR and at least on HLR.

If I don't set the filter just comment out but the remaining code I left untouched, it works. Or whe I set the filter but a very simple one. Seems also to work. I think it's something corrupt with my view created by this way and this let crash DOORS.

vasgyuszi,
who never gives up ;)

llandale - Thu May 12 16:24:49 EDT 2011
Danger Will Robinson DANGER!

I strongly suspect you are a victim of a "Current Module" issue. Add the following code at about line 8:
if (name(m) != name(current Module)) //-
then errorBox("Current Module is '" (name(current Module)) "' but should be '" (name(m)) "'")

If you get that error before the crash then read on, otherwise read on anyway.

Opening a module may or may not set that module 'current'. A few years ago I came up with the exact list of rules that will predict which module is 'current', but then they changed it in the next release. Anyway, opening a module will not necissarily set that module 'current'. Instead of trying to predict which module is in fact going to be 'current', its far safer and more elegant and gives good Karma and keeps the coding gremlins asleep if, for commands that presume the current module, you explicitely set the current module ahead of time.

You use such commands "view(vNam)" and "filtering on/off", there are others.

In your case "current = m" will suffice at about line 8.

What I think is happening is this: it seems as though the first module opens the 2nd module, but when you explicitely open the 2nd, the first module is still "current", causing some havok. This could change over time if the default view of the first module was changed, and now has a layout that queries the 2nd. Its reasonably possibly that the closed 1st module still has a valid 'Module' handle, which becomes in-valid in a couple seconds after you close it, for database syncronization/memory allocation reasons that are far beyond me.

• Louie

vasgyuszi - Thu May 12 17:30:11 EDT 2011

Big THX Louie!

I'll try it right in early tomorrow!

Regarding the code part I copied here, DOORS signalised mostly the line

m = read(mNam, true)

but sometimes the line before:

Module m

as the line where crashed.
That's what I didn't undertand, what can be so dangerous on "Module m" declaration ;)

As you suggest, I'm going to use the explicite current module setting. But than, I have to use it at every places where I'm dealing with modules , across my code in each functions, isn't it?

Thank You and have a good sleep (23:30 at Munich)

vasgyuszi

Mathias Mamsch - Fri May 13 04:42:35 EDT 2011
Louie is right, you need to take care of the current module settings. Anyway I still find it strange that DOORS will crash on a read() call. Maybe that is far fetched, but can you rule out that an attribute DXL, Layout DXL or trigger is crashing the DXL on opening the module? Another reason for crashing on an innocent call like this, is having one or several read functions declared in your code. I experienced problems lately where including the same file (with only functions) twice will lead to crashes, but including it once will work fine. Regards, Mathias

vasgyuszi - Thu May 12 17:30:11 EDT 2011

Big THX Louie!

I'll try it right in early tomorrow!

Regarding the code part I copied here, DOORS signalised mostly the line

m = read(mNam, true)

but sometimes the line before:

Module m

as the line where crashed.
That's what I didn't undertand, what can be so dangerous on "Module m" declaration ;)

As you suggest, I'm going to use the explicite current module setting. But than, I have to use it at every places where I'm dealing with modules , across my code in each functions, isn't it?

Thank You and have a good sleep (23:30 at Munich)

vasgyuszi

llandale - Thu May 12 16:24:49 EDT 2011
Danger Will Robinson DANGER!

I strongly suspect you are a victim of a "Current Module" issue. Add the following code at about line 8:
if (name(m) != name(current Module)) //-
then errorBox("Current Module is '" (name(current Module)) "' but should be '" (name(m)) "'")

If you get that error before the crash then read on, otherwise read on anyway.

Opening a module may or may not set that module 'current'. A few years ago I came up with the exact list of rules that will predict which module is 'current', but then they changed it in the next release. Anyway, opening a module will not necissarily set that module 'current'. Instead of trying to predict which module is in fact going to be 'current', its far safer and more elegant and gives good Karma and keeps the coding gremlins asleep if, for commands that presume the current module, you explicitely set the current module ahead of time.

You use such commands "view(vNam)" and "filtering on/off", there are others.

In your case "current = m" will suffice at about line 8.

What I think is happening is this: it seems as though the first module opens the 2nd module, but when you explicitely open the 2nd, the first module is still "current", causing some havok. This could change over time if the default view of the first module was changed, and now has a layout that queries the 2nd. Its reasonably possibly that the closed 1st module still has a valid 'Module' handle, which becomes in-valid in a couple seconds after you close it, for database syncronization/memory allocation reasons that are far beyond me.

• Louie

vasgyuszi - Mon May 16 08:00:51 EDT 2011

This is the part of the scripts that causes the crash. This works now stand alone, but still makes trouble:
 

//< outsourced view set for special case of HRCX
/* no restriction for total runtime (no more timeouts will be reported)        */
pragma runLim, 0 
 
const string trgPrj     = "/X_reserved_1",
             fldModules = "/Modules"
 
/* ----------------------------------------------------------------------------------------- */
// prepare special views within radio module HRCX for CRCx and CPLD
void prepareView (string mNam, string vNam)
{
    Module m = read(mNam, true)
    if (null m) {errorBox "Module couldn't open: " mNam; return}
    else current = m
 
    ViewDef vDef
    string nam
    for nam in views m do if (nam == vNam) {vDef = get(view vNam); delete vDef; delete view vNam}
 
    View v = view(vNam) // create the view newly
 
    Filter f
  
    Filter f_reqid
    
    Buffer vNamBuf = create
    vNamBuf = vNam
    if(-1!=contains(vNamBuf,"CPLD",0)) f_reqid = contains (attribute "Req.ID", "PLD_", true)
    else f_reqid = !contains (attribute "Req.ID", "PLD_", true)
 
    Filter f_objhead   = notNull attribute "Object Heading"
    Filter f_reqtype   = attribute "Req.-Type" == "SW"
    Filter f_alloc     = attribute "Allocation" == "SW"
    Filter f_radiotype = contains(attribute "RadioType", "M3AR Family", true) ||
                         contains(attribute "RadioType", "MR6000A",     true) ||
                         contains(attribute "RadioType", "MR6000Aenh",  true)
    
    Buffer mNamBuf = create
    mNamBuf = fullName m
    
    if     (-1!=contains(mNamBuf,"TC_", 0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "TC_", true)  && f_alloc     && f_radiotype )
    else if(-1!=contains(mNamBuf,"LLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "LLR_", true) && f_radiotype                )
    else if(-1!=contains(mNamBuf,"HLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "HLR_", true) && f_reqtype   && f_radiotype )
    else if(-1!=contains(mNamBuf,"SLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "SLR_", true) && f_radiotype )
    else errorBox "There is no appropriate DOORS module to filter." // no appropriate DOORS module
 
    set(m,f)
    filtering on
    showDeletedObjects(false)
 
    setempty(mNamBuf)
    delete(mNamBuf)
 
    setempty(vNamBuf)
    delete(vNamBuf)
      
    vDef = createPublic(m, true)
    current = first m
    useCurrent(vDef,true)
    useWindows(vDef,true)
    save (v, vDef)
 
    close m
 
}//void prepareView (string mNam, string vNam)
 
/* special handling of radio module HRCX, because the SW part of it contains both the CRCx and CPLD software also */
prepareView(trgPrj fldModules "/HRCX/TC_HRCX"    , "CRCx DO-Release view")
prepareView(trgPrj fldModules "/HRCX/LLR_SW_HRCX", "CRCx DO-Release view")
prepareView(trgPrj fldModules "/HRCX/HLR_HRCX"   , "CRCx DO-Release view")
 
prepareView(trgPrj fldModules "/HRCX/TC_HRCX"    , "CPLD DO-Release view")
prepareView(trgPrj fldModules "/HRCX/LLR_SW_HRCX", "CPLD DO-Release view")
prepareView(trgPrj fldModules "/HRCX/HLR_HRCX"   , "CPLD DO-Release view")

What could I try next?

Best regards,
vasgyuszi

vasgyuszi - Mon May 16 08:00:51 EDT 2011

This is the part of the scripts that causes the crash. This works now stand alone, but still makes trouble:
 

//< outsourced view set for special case of HRCX
/* no restriction for total runtime (no more timeouts will be reported)        */
pragma runLim, 0 
 
const string trgPrj     = "/X_reserved_1",
             fldModules = "/Modules"
 
/* ----------------------------------------------------------------------------------------- */
// prepare special views within radio module HRCX for CRCx and CPLD
void prepareView (string mNam, string vNam)
{
    Module m = read(mNam, true)
    if (null m) {errorBox "Module couldn't open: " mNam; return}
    else current = m
 
    ViewDef vDef
    string nam
    for nam in views m do if (nam == vNam) {vDef = get(view vNam); delete vDef; delete view vNam}
 
    View v = view(vNam) // create the view newly
 
    Filter f
  
    Filter f_reqid
    
    Buffer vNamBuf = create
    vNamBuf = vNam
    if(-1!=contains(vNamBuf,"CPLD",0)) f_reqid = contains (attribute "Req.ID", "PLD_", true)
    else f_reqid = !contains (attribute "Req.ID", "PLD_", true)
 
    Filter f_objhead   = notNull attribute "Object Heading"
    Filter f_reqtype   = attribute "Req.-Type" == "SW"
    Filter f_alloc     = attribute "Allocation" == "SW"
    Filter f_radiotype = contains(attribute "RadioType", "M3AR Family", true) ||
                         contains(attribute "RadioType", "MR6000A",     true) ||
                         contains(attribute "RadioType", "MR6000Aenh",  true)
    
    Buffer mNamBuf = create
    mNamBuf = fullName m
    
    if     (-1!=contains(mNamBuf,"TC_", 0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "TC_", true)  && f_alloc     && f_radiotype )
    else if(-1!=contains(mNamBuf,"LLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "LLR_", true) && f_radiotype                )
    else if(-1!=contains(mNamBuf,"HLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "HLR_", true) && f_reqtype   && f_radiotype )
    else if(-1!=contains(mNamBuf,"SLR_",0))  f = f_objhead || ( f_reqid && contains (attribute "Req.ID", "SLR_", true) && f_radiotype )
    else errorBox "There is no appropriate DOORS module to filter." // no appropriate DOORS module
 
    set(m,f)
    filtering on
    showDeletedObjects(false)
 
    setempty(mNamBuf)
    delete(mNamBuf)
 
    setempty(vNamBuf)
    delete(vNamBuf)
      
    vDef = createPublic(m, true)
    current = first m
    useCurrent(vDef,true)
    useWindows(vDef,true)
    save (v, vDef)
 
    close m
 
}//void prepareView (string mNam, string vNam)
 
/* special handling of radio module HRCX, because the SW part of it contains both the CRCx and CPLD software also */
prepareView(trgPrj fldModules "/HRCX/TC_HRCX"    , "CRCx DO-Release view")
prepareView(trgPrj fldModules "/HRCX/LLR_SW_HRCX", "CRCx DO-Release view")
prepareView(trgPrj fldModules "/HRCX/HLR_HRCX"   , "CRCx DO-Release view")
 
prepareView(trgPrj fldModules "/HRCX/TC_HRCX"    , "CPLD DO-Release view")
prepareView(trgPrj fldModules "/HRCX/LLR_SW_HRCX", "CPLD DO-Release view")
prepareView(trgPrj fldModules "/HRCX/HLR_HRCX"   , "CPLD DO-Release view")

What could I try next?

Best regards,
vasgyuszi

Mathias Mamsch - Mon May 16 08:44:53 EDT 2011
Hmm ... I am reading that code again and again, I cannot find a good reason for a crash. You say
the script crashes only in conjunction with the other scripts, but not when you run it on its own.
That suggests that there is something wrong with the other scripts. The general strategy to find the
reason would be in my opinion:

1. Rule out alien module intervention
Replace the modules that you are working with, by dummy modules without any views, attribute DXL or
triggers. For this make a copy of the affected modules to a new project, replace all DXL attributes,
remove the views and delete all the triggers. If the error persists you can rule out module intervention.

• 2. Rule out bugs in other scripts*

SystemAdmin - Mon May 16 09:21:35 EDT 2011
From your earlier posting: "If I don't set the filter just comment out but the remaining code I left untouched, it works."

Check the enumerated attribute definitions in your modules, I had a similar problem with one script crashing. I finally isolated it to error in setting a filter: the script tried to filter based on single-value attribute, but in the module the attribute was defined as multivalue.

Mathias Mamsch - Mon May 16 08:44:53 EDT 2011
Hmm ... I am reading that code again and again, I cannot find a good reason for a crash. You say
the script crashes only in conjunction with the other scripts, but not when you run it on its own.
That suggests that there is something wrong with the other scripts. The general strategy to find the
reason would be in my opinion:

1. Rule out alien module intervention
Replace the modules that you are working with, by dummy modules without any views, attribute DXL or
triggers. For this make a copy of the affected modules to a new project, replace all DXL attributes,
remove the views and delete all the triggers. If the error persists you can rule out module intervention.

• 2. Rule out bugs in other scripts*

Mathias Mamsch - Mon May 16 08:44:53 EDT 2011
Hmm ... I am reading that code again and again, I cannot find a good reason for a crash. You say
the script crashes only in conjunction with the other scripts, but not when you run it on its own.
That suggests that there is something wrong with the other scripts. The general strategy to find the
reason would be in my opinion:

1. Rule out alien module intervention
Replace the modules that you are working with, by dummy modules without any views, attribute DXL or
triggers. For this make a copy of the affected modules to a new project, replace all DXL attributes,
remove the views and delete all the triggers. If the error persists you can rule out module intervention.

• 2. Rule out bugs in other scripts*

vasgyuszi - Mon May 16 11:20:59 EDT 2011
@Mathias and Pekka:

Sorry guys, none of your hints helped. Neither the elimination of any user related views, nor the reconstructing of filter on multi-valued attribute.

BUT: I identified a place more precise, what the crash cause.
This is the main filter. As long as I'm using System Attributes to create the main filter "f" is everything fine, but when I start using user created attributes for filtern, it crash. Very strange.

regards,
vasgyuszi

SystemAdmin - Mon May 16 13:57:07 EDT 2011
Can you set the same filter in the DOORS GUI (Tools / Filter / Define)?

llandale - Mon May 16 16:27:51 EDT 2011
Still stumped. Maybe there is some Rogue DXL running that you don't know about.
Open your module and run the attached DXL, copy to notepad, and see what's what.
The DXL will find all Layout and AttrDXL and Triggers that are associated with
the module; for Triggers that includes those in parent Projects and the Database.

Perhaps post the results, but it would be nice if you separated out the individual
scripts first.

Sorry its sloppy, it was restricted to 75 lines of code.

Are you sure there are not more DXL errors you can post? Hey other folks: cannot we
use some sort of debug tracing to find out the sequence of function calls so we
can better determine what is exactly going wrong?

• Louie

SystemAdmin - Mon May 16 13:57:07 EDT 2011
Can you set the same filter in the DOORS GUI (Tools / Filter / Define)?

llandale - Mon May 16 16:27:51 EDT 2011
Still stumped. Maybe there is some Rogue DXL running that you don't know about.
Open your module and run the attached DXL, copy to notepad, and see what's what.
The DXL will find all Layout and AttrDXL and Triggers that are associated with
the module; for Triggers that includes those in parent Projects and the Database.

Perhaps post the results, but it would be nice if you separated out the individual
scripts first.

Sorry its sloppy, it was restricted to 75 lines of code.

Are you sure there are not more DXL errors you can post? Hey other folks: cannot we
use some sort of debug tracing to find out the sequence of function calls so we
can better determine what is exactly going wrong?

• Louie

vasgyuszi - Tue May 17 06:46:43 EDT 2011

@Louie: I let run your courtesy script on the three affected modules:
 

>>>>>>>>>>> Results Follow <<<<<<<<<<<<<<
DxlFind.dxl for module 'HLR_HRCX',
    </X_reserved_1/Modules/HRCXtry/HLR_HRCX>
        >>>>>>>>AttrDXL: none found
        >>>>>>>>LayoutDXL: none found
        >>>>>>>>TriggerDXL-Mod: none found
        >>>>>>>>TriggerDXL-Prj: none found
        >>>>>>>>TriggerDXL-Database 'dynamic 104':  FoundIn 'Database'  post-open-module:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 105':  FoundIn 'Database'  post-close-module:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 0':  FoundIn 'Database'  post-drag-object:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 1':  FoundIn 'Database'  post-drop-object:
 
 
>>>>>>>>>>> Results Follow <<<<<<<<<<<<<<
DxlFind.dxl for module 'LLR_SW_HRCX',
        </X_reserved_1/Modules/HRCXtry/LLR_SW_HRCX>
        >>>>>>>>AttrDXL: none found
        >>>>>>>>LayoutDXL: none found
        >>>>>>>>TriggerDXL-Mod: none found
        >>>>>>>>TriggerDXL-Prj: none found
        >>>>>>>>TriggerDXL-Database 'dynamic 104':  FoundIn 'Database'  post-open-module:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 105':  FoundIn 'Database'  post-close-module:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 0':  FoundIn 'Database'  post-drag-object:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 1':  FoundIn 'Database'  post-drop-object:
 
 
>>>>>>>>>>> Results Follow <<<<<<<<<<<<<<
DxlFind.dxl for module 'TC_HRCX',
        </X_reserved_1/Modules/HRCXtry/TC_HRCX>
        >>>>>>>>AttrDXL: none found
        >>>>>>>>LayoutDXL: none found
        >>>>>>>>TriggerDXL-Mod: none found
        >>>>>>>>TriggerDXL-Prj: none found
        >>>>>>>>TriggerDXL-Database 'dynamic 104':  FoundIn 'Database'  post-open-module:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 105':  FoundIn 'Database'  post-close-module:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 0':  FoundIn 'Database'  post-drag-object:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 1':  FoundIn 'Database'  post-drop-object:

Nothing suspicious for the forst looking...

SystemAdmin - Tue May 17 01:56:46 EDT 2011
Well, there is the DXL tracing, copying from somewhere:

"A neat undocumented debugging trick for DOORS 8.

put the following above the code you want to debug:-
startDXLTracing_("C:\\Your Dir\\Your File.txt")

and the following beneath the code to be debugged: -

stopDXLTracing_

Run the code and open the file you've created, made my life a little bit easier, might make yours easier to?"

But this is output only the variable values in the style:

<Line:121> itm = 0x39d6780
<Line:53> isInherited = _ false = 0
<Line:54> ItemType = _
<Line:56> ItemType = da37 itm = 0x39d6780
<Line:57> ItemType = "Project" ItemType = "Project"
<Line:59> ItemType = "Project" itm = 0x39d6780
<Line:70> itm = 0x39d6780 isInherited = 0
<Line:72> isInherited = true

llandale - Tue May 17 11:09:09 EDT 2011
Something is Rotten in Denmark and I think I need help.

I know of no way to retrieve the DXL code for Dynamic (nor Built-In) Triggers and so I don't print it from that script; and sadly I know of no way to figure out what these triggers are doing. My Trigger functions are several years old and its possible there is more information to be retrieved from these triggers, but I doubt it.

Running the code on my module I see these triggers exist also, and this is confirmed with my standard find-the triggers script.

>>>>>>>>TriggerDXL-Database 'dynamic 0': FoundIn 'Database' post-drag-object:
>>>>>>>>TriggerDXL-Database 'dynamic 1': FoundIn 'Database' post-drop-object:

.. so I suppose they are supposed to be there for whatever reason.

However, these triggers are NOT in my database and look REAL suspitious:

>>>>>>>>TriggerDXL-Database 'dynamic 104': FoundIn 'Database' post-open-module:
>>>>>>>>TriggerDXL-Database 'dynamic 105': FoundIn 'Database' post-close-module:

Not familiar with "dynamic database" triggers but presume they mean they are created during your session and are not saved when you exit DOORS.

The large "104" and "105" numbers make me suspect that other dynamic triggers have been created (such as to close a dialog box), but later these triggers are created. In any case it appears to me that the "post-open-module" trigger is doing something unpleasant; like closing the module. Start a new DOORS session and re-run DxlFind and I think we will see these number are much smaller.

If you are a 'database admin' or 'Administrator' you should create a new DOORS icon that disallows with the "-T" ('no-Triggers') command line switch, then try my DXLFind script and also run your problematic code. c:\Program Files\blablabla\doors.exe -T

You need also to figure out where those dynamic triggers are coming from, but frankly I don't know how to go about doing that.

• Louie

llandale - Tue May 17 11:09:09 EDT 2011
Something is Rotten in Denmark and I think I need help.

I know of no way to retrieve the DXL code for Dynamic (nor Built-In) Triggers and so I don't print it from that script; and sadly I know of no way to figure out what these triggers are doing. My Trigger functions are several years old and its possible there is more information to be retrieved from these triggers, but I doubt it.

Running the code on my module I see these triggers exist also, and this is confirmed with my standard find-the triggers script.

>>>>>>>>TriggerDXL-Database 'dynamic 0': FoundIn 'Database' post-drag-object:
>>>>>>>>TriggerDXL-Database 'dynamic 1': FoundIn 'Database' post-drop-object:

.. so I suppose they are supposed to be there for whatever reason.

However, these triggers are NOT in my database and look REAL suspitious:

>>>>>>>>TriggerDXL-Database 'dynamic 104': FoundIn 'Database' post-open-module:
>>>>>>>>TriggerDXL-Database 'dynamic 105': FoundIn 'Database' post-close-module:

Not familiar with "dynamic database" triggers but presume they mean they are created during your session and are not saved when you exit DOORS.

The large "104" and "105" numbers make me suspect that other dynamic triggers have been created (such as to close a dialog box), but later these triggers are created. In any case it appears to me that the "post-open-module" trigger is doing something unpleasant; like closing the module. Start a new DOORS session and re-run DxlFind and I think we will see these number are much smaller.

If you are a 'database admin' or 'Administrator' you should create a new DOORS icon that disallows with the "-T" ('no-Triggers') command line switch, then try my DXLFind script and also run your problematic code. c:\Program Files\blablabla\doors.exe -T

You need also to figure out where those dynamic triggers are coming from, but frankly I don't know how to go about doing that.

• Louie

vasgyuszi - Thu May 19 02:34:46 EDT 2011

Well, I've made a new run.

A fresh started DOORS for one of the modules of my choice delivers:
 

>>>>>>>>>>> Results Follow <<<<<<<<<<<<<<
DxlFind.dxl for module 'TC_HRCX',
    </X_reserved_1/Modules/HRCXtry/TC_HRCX>
        >>>>>>>>AttrDXL: none found
        >>>>>>>>LayoutDXL: none found
        >>>>>>>>TriggerDXL-Mod: none found
        >>>>>>>>TriggerDXL-Prj: none found
        >>>>>>>>TriggerDXL-Database 'dynamic 0':  FoundIn 'Database'  post-drag-object:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 1':  FoundIn 'Database'  post-drop-object:

No sign of suspicious triggers :)
With this fresh DOORS instance I was able to run twice in a row successfully. But not any more and crash again and again.

regards,
vasgyuszi

vasgyuszi - Thu May 19 02:34:46 EDT 2011

Well, I've made a new run.

A fresh started DOORS for one of the modules of my choice delivers:
 

>>>>>>>>>>> Results Follow <<<<<<<<<<<<<<
DxlFind.dxl for module 'TC_HRCX',
    </X_reserved_1/Modules/HRCXtry/TC_HRCX>
        >>>>>>>>AttrDXL: none found
        >>>>>>>>LayoutDXL: none found
        >>>>>>>>TriggerDXL-Mod: none found
        >>>>>>>>TriggerDXL-Prj: none found
        >>>>>>>>TriggerDXL-Database 'dynamic 0':  FoundIn 'Database'  post-drag-object:
 
        >>>>>>>>TriggerDXL-Database 'dynamic 1':  FoundIn 'Database'  post-drop-object:

No sign of suspicious triggers :)
With this fresh DOORS instance I was able to run twice in a row successfully. But not any more and crash again and again.

regards,
vasgyuszi